home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000218_news@columbia.edu_Mon Nov 21 01:43:13 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04611
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 21 Nov 1994 12:24:40 -0500
  3. Received: by apakabar.cc.columbia.edu id AA02127
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 21 Nov 1994 11:31:48 -0500
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!news.kei.com!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Telnet Data Mark displays as "r" on MSK 3.13.
  9. Message-Id: <1994Nov21.074313.33432@cc.usu.edu>
  10. Date: 21 Nov 94 07:43:13 MDT
  11. References: <785307785snx@djwhome.demon.co.uk>
  12. Organization: Utah State University
  13. Lines: 35
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <785307785snx@djwhome.demon.co.uk>, david@djwhome.demon.co.uk (David Woolley) writes:
  17. > When an interrupt signal is generated on our SCO machines
  18. > (3.2V4.2), MS-Kermit (3.13, patch about 13, but there are no
  19. > obvious fixes listed up to patch 20**) displays an "r".  NCSA
  20. > Telnet handles this correctly, and examining the event trace
  21. > shows that a Telnet Data Mark signal is being sent.
  22. > 
  23. > This happens for both Telnet interrupts, and interrupts generated
  24. > by sending the stty interrupt character.
  25. > 
  26. > This is really only a cosmetic problem, and normally results from
  27. > being too lazy to change the interrupt character or remap the
  28. > backspace key before talking to the machine in question.  It
  29. > doesn't happen for SunOS 4.1.1.
  30. > 
  31. > ** the patch level 20 file is at home, not in the office.
  32. --------
  33.     Data Marks are rather rare events, but you ought not have seen
  34. an "r" as a consequence. DMARK is 242 decimal, which after chopping the
  35. high bit yields 114 decimal "r". But the DMARK should have been sent as
  36. IAC DMARK (255 242), and the Kermit Telnet code would (quotes) have absorbed
  37. both bytes.
  38.     If you are still reading along, the way I understand this situation 
  39. is the SCO machine was trying to flush bytes sent to the MSK client, by 
  40. sending IAC DMARK in a TCP segment with the TCP URGENT bit set. The recepient
  41. is supposed to discard all data up to and including the IAC DMARK. Folks have 
  42. commented upon this less than clear or desirable "feature" of Telnet, and 
  43. Kermit does not play that game. Just how much discarding should occur is 
  44. ambiguous, and I chose not to chase down internal buffers to do the flush. 
  45. In any case, the commands are really intended to be sent to servers where a 
  46. job may be blocked unable to read the data stream for the Interrupt Process 
  47. command pair IAC IP or similar; they ought not be sent to clients.
  48.     If you still have the trace I'd appreciate receiving a copy.
  49.     Thanks,
  50.     Joe D.